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APPLE IT UTILITY PACK 


Leserivtion and Instructions for Program Use: 


ADDRESS CONVERSION: (3.8K) 


3 On the Apple II, an address (or any number for that matter) can be 
expressed in four ways. In Integer BASIC, all numbers above 32767 are 
expressed as a negative number. In Applesoft, any address from 65535 

to +65535 can be directly stated. The number also has a hexadecimal form 
(base 16). Last of all, any number up to 65535 can be stored in two bytes 
(such as in the case of line #'s and address -pointers). 

To use the program, "RUN ADDRESS CONVERSION' will do the trick. After 
the title banner appears, press any key to proceed. Then enter any number 
from -65535 to 65535 (or in hex notation, $@ to $FFEF), and it will be 
displayed in all formats. | 

Examples: a) Suppose you wanted to know the hex address referred 

to by a ‘CALL -936'. When the program asks the number 

to be evaluated, you would enter '-936'. The program 
will return *SFC58' as the hex address for the routine. 
Also given will be 252 and 88 as the two byte form (dec= 
imal) of the number, and 64690 as the actual decimal 
adcresse | 

b) Suppose you find the numbers '25' and '175" as the 
decimal numbers to place in a pair of pointers some- 
where in memory as part of a BASIC program, and you 
would like to know the address referred to by these. 
When the vrogram asks you for your number, enter a 
'Control-A' only, followed by RETURN.. The program will 
then ask for the High- and Low-order bytes. Enter 175 
and 25 (assuming 175 was the high-order byte) and the 
program will return -29711, 44825 and $AF19 as the 
various forms of the number represented by those two 
bytes. You will notice that under High- and low-order 
bytes your '175' becomes '175/$AF". This corresponds to 
the first two dicits of the hex number $AF19. if you 
have the two bytes of an address in hex, it is easy to 
determine the final number by simply putting the two 
together. 


SCREEN FIND: (4.3K) 


Characters may be directly displayed on the Apple II's screen by 
'POKE'ing the proper value into memory locations $400 to $7FF for pg. i 
and $800 to $BFF for pg. 2. This program will determine the proper 


address in memory and the value to enter there for the desired character. 
To use the program 'RUN SCREEN FIND’ in the usual manner. Then enter 
the horizontal and vertical position for the character just as you would 
normally specify a HTAB (from 1 to 4G) and VTAB (from 1 to 24) state- 
ment. Then enter the character, and whether it is to be displayed in 
normal, inverse, or flashing mode. The program will then return the 
appropriate memory location, and the decimal and hex. values to put there. 
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The heart of the proeram is on lines 440 & 450. You may find this of 
use in other programs of your own. There are RiM statements at the end of 
the program to explain each variable of the equation. In general, the 
equation returns the mrmory address desired, given the horizontal and vertical 
tab positions. You may find the article, ‘An Apple II Page 1 Map’ by M.R. 
Connolly Jr. in Dece-dan '79 (pg. 8-41) in MICRO magazine to be of interest. 
If you are interested in outoutting characters to the screen from machine 
language, you may be interested in using the BASCALC routine in the Monitor 
at $FBC1. Just put the vertical position (from 9 to 39) in the Accumulator, 
then JSR to $FBC1i. The routine will deposit the low- and high-order bytes 
for the first position of the horizontal line at that vertical spot in $28 
and $29, respectively (40 and 41 decimal). ‘Then add whatever the horizontal 
displacement is to that value. (starting at @ for the left margin, 39 for 
the right). 
It is beyond the scope of this documentation to go inot further detail 
on how to use machine language, but perhaps the above hints will be helpful. 


If you would like to print on Page 2 of text from BASIC, you may wish 
to experiment with the program below: 


10 LOMEM: 3072 

20 DIM A$(10) | 
30 FOR I=2048 to 3071: POKH 1,160: NEXT I 
40 CALL 936 

50 INPUT" H,V ON PG. 2* .H,V 

60 VTAB V: TAB H: PRINT "*; 

70 POKE -16299,¢ 

86 POKE 41, PHEK(41) +4 

90 PRINT "THIS IS A TEST"; 

10@ INPUT A$ 

110 POKE ~16300,@ 

126 PRINT : GOTO 59 


This is inspired by Andy Hertzfeld's article in the San Francisco Apple 
Core's Newsletter, The Cider Press, Vol.2, No. 2. Basically the idea is to 
let the Monitor calculate a horizontal and vertical position (#69). Then 
change the pointer in 41 to page 2. (#80). Thereafter, everything printed will 
appear on vage 2 until the next carriage return, line feed, or VIAB. Each time 
you begin a new line the POKE must be repeated. 

If you are unsure of how to put LOMEM: into a program, see the section on 
the internal structure of Integer in this documentation. Otherwise, omit this 
line and type it in manually before running the program. #30 clears pg. 2 by 
POKEing the value for a space into each location. #79 switches the display to 
page 2, #119 back to page 1. 

You may wish to re-write the Monitor's scrolling routine in a location in 
RAM for use with page 2. Another of my programs, ‘ROGER*'S EASZL" makes use of 
this to allow the user to access help instructions at any time during the pro-~ 
gram. You might want to examine the machine language portion at the end of that 
program to see how page 2 can be used for this. 
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RENUMBER=I: (9.4K) 


This utility renumbers all line #'s from $ to 65023 at the increment 
of your choice in any Integer Basic program. You may renumber with new line 
#*s as high as 65535. The reason for the limit on numbers you can change is 
to orotect copyright statements in other programs from being changed or 
deleted. You may wish to put your own statements at the end of your programs 
and number them at 65535 with this program. 

During the renumbering process, all GOTO's, ete. are also renumbered, 
and you are alerted to any referenced lines not in the program. You are 
also alerted to any GOTO’s, ete. followed by a variable or expression. 

To use the program, your program should already be in memory. (LOAD 
it normally if it is not.) Then type '=XEC RENUMEER-I’. The disk drive will 
come on and you will see a series of prompts on the screen. The title banner 
will then appear, at which time you can press any key to proceed. 

The program will ask where in your program you would like the renumbering 
process to start at, what new line # to put there, what amount to increment 
each succeeding line, and where to end the renumbering at. If you wish to 
have several line numbers with the same # you may do this by giving an incre- 
ment size of '0*, (Such as for copyright statements at the end of programs) 

You may default on these inputs with the following results: Pressing 
"RETURN' only for the starting point will default to '%*. The new number to 
be vut there defaults to "10" as does increment size. The line to end on will 
default to 65023. To renumber an entire program, starting with '19' and 
incrementing by °19%s, just press 'RETURN’ alone in response to each question. 

Pecause the greates amount of time spent by the routine is searching 
for GOTO's, etc. if you are renumbering only REMark statements you may elect 
not to do this search and renumber line #'s only. ‘This question when asked 
defaults to searching for GOTO's. 

If for some reason (such as hitting "RESET" or 'Control-C') the program 
is halted, you may recover your original program (partly renumbered) with a 
"GOTO 570". You may reeactivate the routine with a ‘CALL RN* or a CALL to 
the number given when the program terminated. This is of course, providing 
you don't change too many lines in your program so as to overewrite the 
location of the renumbering program. (About 500 bytes below your program) 

The renumbering takes about 40 seconds per iK of your program to do tne 
complete renumbering. 


RENUMBER-I(S): (5.2K) 


This program is a shorter version of the above, intended for use in 
machines with 16 or 32K of memory. It will NOT work in a 48K machine. Cther-~ 
wise, it is identical in function and use to the above program. 
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RENUMBER@A/S: (5.3K) 


'EXSC RENUMBER-A/S' to use this program. The main difference between 
this and the Integer version (besides the obvious fact that this is 
intended for use with Applesoft programs) are first, that the limit to 
line numbers you can change is 65909. Some other features include a display 
of the lines it is currently working on (more entertaining than watching a 
blank sereen...) and more sophistication in checking for renumbering problems, 
such as new numbers going out of range, or an overlap or conflict when you 
are renumbering just portions of a program. If you halt the program with a 
*Control-C* you will immediately recover your program. (again, partly re- 
numbered). If you should happen to hit "RESET*® you may recover your program 
with a 'Control=C’ followed by 'GOTO 760°. 

You may default on any question by pressing ‘RETURN’ alone. Renumbering 
takes about 10 seconds for each 1K of your program length. 


LINE FIND-I: (3.9K) 


"EXEC LINE FIND-I* to usee Hnter the line number you're looking for 
and this routine will return the decimal and hex. eddresses of that line's 
location in memory. Your program should already be in memory before using 
this routine. Later sections in this documentation (Internal structure of 
Integer / Applesoft) more fully explain varius uses of this and the Apple- 
soft version of these programs. 


LINE FIND-A/S: (3.2K) 


*EXHC LINE FIND-A/S* to use. The same in function and use as the above 
program, but for use with Applesoft programs. 


APPEND@A/S: (GK) 


This routine will allow you to add one Applesoft program directly to 
the end of another. This is especially useful for adding copyrights and often 
used suberoutines to the end of programs. To use, normally load your first 
program (to be at the beginning of the final version) if it is not already in 
memory. Then set A$ = 'NAME* where NAME is the name of the other program to 
be added onto the end of the first program. This second program must already 
be on the same disk as the APPEND-A/S routine. Then type *EXEC APPEND-A/S® 
and the program on the.disk will be appended to the one currently in memory. 

If you have too many programs to be appended to be put on the utility 
disk you may use the APPEND FILE CREATE vrogram which will put the APPEND 
EXEC’ file on any disk you wish. The program is self-documenting. 


APPEND=I: (@K) 


This is very similar to the above routine. However, since Integer is 
structured a little differently, programs appended to ones already in memory 
will appear at the beginning of the final listing, as opposed to at the end 
as in Applesoft. You must also remember to dimension A$ before setting it 
equal to the name of the program to be appended. 'DIM A$(4@)* in the immediate 
mode will be sufficient. APPEND FILE CREATE will also create the Integer 
Append file on any disk of your choice. 


Af 
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VAL: 


This is included as a demonstration of how to simulate Applesoft's 
VAL( ) function in Integer. You can use lines 329005 and 32910 as a sub- 
routine, or vut them directly in the program where you need the VAL( ) 
function at that point. VAL( ) converts a string to a number. See the 
Applesoft Reference Manual, pg. 59, for further details. 


STRS: 


Similar to above, but this time a simulation of Applesoft's STR3( ) 
function. (Converts a number to a string.) 


MOVE 

A machine language routine to move blocks of memory up or down, by 
any increment you wish, even one byte. There is a routine in the Monitor 
similar to this, but it will only move blocks down if you wish to move only 
a few bytes. (It will work in either direction providing the distance moved 
is greater than the length of the block). ‘The other drawback is that the 
Monitor routine is difficult to execute from Applesoft. The routine on this 
Utility Pack can be used from either Integer or Applesoft. It is useful, for 
example, for moving text or graphics (High= or Low-res.) from pg. 1 to pg. 2 
or back. See the green Applesoft Manual, pg. 126 for appropriate addresses 
for this. Also, the Sept. 1978 issue of CONTACT, the Apple II newsletter 
discusses this. The machine language routine resides from $30@ to $33F. 

To use the MOV= routine from within a program, some pointers must be 
set for the beginning and end of the block you wish to move. In general, 
these are: 


(1) POKE 6@, old start addr. MOD 256 (2) POKE 62, old end addr. MOD 256 


POKE 61, old start addr. / 256 POKE 63, old end addr. / 256 
(3) POKE 64, new end addr. MOD 256 (4) POKE 66, new start addr. MOD 256 
POKE 65, new end addr. / 256 POKE 67, new start addr. / 256 


To execute the move: (assuming MOVE has already been *BLOAD‘ed) 


‘CALL 768" for a move up (#4 not needed for this) 
‘CALL 817 for a move down (#3 not needed for this) 


Since Applesoft does not have the MOD and '/" functions of Integer, you 
will need to make use of the following relationships: 


X MOD Y (in Integer) is equivalent to... X = INT(X/Y)*¥ (in Applesoft) 
REY is equivalent to... INT(X/Y) 


UPDATES AND CORRECTICNS: Be sure to mail your reply card so as to be notified 
of any changes or additions on these programs. Any comments or suggestions 
you may have as to improvements in the programs is also appreciated. 

Please include them on the response card, or call or write the above addresse 
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LINE FIND = I (AND RELATED TOPICS...) 


LINE FIND-I is designed to allow you to manipulate program lines 
at the machine level. Before going into this however, a brief discussion 
of the way INTEGER Basic program lines are formstted is in order. 


INTERNAL STRUCTURZ CF INT=GER BASIC 


First of all, INTEGER stores the values for the beginning and ending 
voints of any program in certain locations in memory called ‘pointers’, 
Pointers are almost always located in hex addresses $06 to $FF (8 to 
255 decimal). This area of memory is often call the “zero page" of memory. 
Depending on what language you're using (Monitor, INTEGER or APPLESOFT), 
certain addresses are always used for a given pointer. In INTEGER, for 
instance, hex $CA and $CB (dec. 202 and 203) hold the starting address of 
the program currently in memory. If you are in Monitor and you type in 
‘CA CB (CR)' you will get something like this: CA-=} F5 This tells you 

CE=— of 


that stored in location $CA is the value $F5 and in $CB is $BF. These 
two addresses taken together tell you the starting address of the program 
currently in memory is $EFF5. (Note that the leading 2 digits are reversed 
with the last two digits as far as how they are stored in $CA and #CB. 
This is what is meant by the terms “high- and low-order bytes". It takes 
two bytes to store an address in the Apple under most circumstances. The 
first part of the address ($EF in our example) is called the high-order 
byte because it represents the larger part of the number. (Just as in the 
decimal system, for the number '15', the '1" represents a greater value 
than the '5'.) The second part of the address ($F5) is called the low- 
order byte. In the pointers, the low-order byte comes first followed by 
the higheorder byte. 

The end of a program is similarly stored in the zero-page of memory. 
For INTEGER, this is at hex $4C and $4D. (dec. 76 and 77) In the Monitor, 
typing in *4C 4D (CR)* might get you something like this: 4C= 90 This 

4D- CO 


would indicate that the program ended at the address $C@06. 

Now, how are the individual lines formatted? The best way to find 
this out is by example, aided by the page included in the documentation. 
This page has “INTEGER TOKz£NS" in the upper left corner. 

For starters, make sure your Apple is properly initialized by hitting 
"RESET’, followed by a ‘Control-B* to get into INTEGEH Basic. Now type in 
this simple vrogram: 1@ GOTO 2¢ 

2% END 


LIST and check to make sure it is identical to the example. Now to 
examine this at the machine level, type in 'CALL -151' or hit ‘RESET’ to 
get into the Monitor. Now find the beginning and end of the program by 
looking at the pointers at $CA,CB,4C and 4D. 
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Do this by typing in 'CA CB 4C 4D (CR)'. This should yield: 


OECA- F3 (This is for a 48K machine. If you have a 16K 
OOCB- EF or 32K the numbers 2t $CB ard S4C will change 
SO4C- BY accordingly...) 

GC4D= CH 


This tells us the vrogram resides from $BFF3 to $C@@% in memory The 
program is short enough we can examine its entirety by typing in: 
'BFF3.CQ00@ (CX)* This should give: 


BFF3- G8 OA OO SF E2 (Do not be concerned if the value at 
BFFS8.{ 14 00 G1 65 14 60 51 O1 $COG0 is rot '@D'. This is not actually 
CEOO- OD part of your program, but the very next 


byte after it...) 


Referring to the two pages of INTEGER tokens, we can decode this data 
to see how the vrogram is stored. ‘The reason they are called ‘tokens’ is 
because often-used varts of a orogram, namely the commands anc statements, 
are encoded in a single number for the entire word. For example, every- 
where you have the command *GOSUB’ in a program, the computer stores this 
as a hexadecimal number, $5C. This provides a great space savings by using 
this technique. A few other fundamentals: 1) Every line begins with one 
byte that gives the length of the tokenized line. 2) The next two bytes 
store the line # in low- and high-order bytes. In fact, every constant or 
line # in INTEGER is stored using the low- and high-order bytes. 3) Hach 
line has a '@1' at the end of the line to indicate the end. 

Let's look at the program itself. At $BFF3, the first byte is '#8'. 
This tell the computer (and us) t~at the line is a total of eight bytes 
long. ‘The next two bytes, "GA" and *@0" are the low=- and high-order bytes 
for the line #, in this case '16'. You may use the program "ALDRESS/HEX 
CONVERTER" to determine the low- 2nd high-order bytes for any number. The 
next byte, '5F' is the token for 'GOTC’. (Check 3rd column, first pg. to 
confirm) If you had tyoed 'GOSUB 20" this would have been '5C'. Now a bit 
of a peculiarity. The next byte is 'B2'. This is the ASCII value for the 
digit '2*, the first digit of the number following the ‘GOTO’ in your 
orogram. If you had written ‘GOTO 5000" this byte would have been 1S 
the ASCII value for '5*. The following two bytes store the number '20! 
in the low- and high-order bytes '14' and '06'. Every constant and ref- 
erenced line number therefore takes a total of 3 bytes to store it in 
INTEGER Basic. The last byte of the line is the '@1' at $BFFA. This 
indicates the end of the first line. 

The format continues in a similar pattern for the next line. '@5' 
shows the line is 5 bytes long. ‘'14' and '@@" encede the line number, in 
this case '20', '51" is the token for ‘END® and 191" is the end of the line, 
and in this case, the end of the program. Note that the pointer at $4C,4D 
always voints at the next byte after the end of the program. 
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SOME USES CF Thr LINE FIND PROGRAM 


First, an experiment. Use Control-3 to remwenter INTEGER Basic and 
type in 'NEW'. Supnose you were writing a program, and you wanted to clear 
the variables to '%* at some point. Simple enough, use the CLR command, 
right? Not quite. Type in the following line: ZY, Crit’ 

Having difficulty? This is because INT#G“R Basic does not directly 
accept CLR as a legal syntax when typing in your line. This does not, 
however, mean that you are out of luck. There is a way! 

Tvoe in this: ‘19 REM’ Now find out where your peer is 
at in memory by looking at the pointers as discussed earlier. Type i 
‘CALL #151* or hit ‘RESET’ to enter the Monitor. Now enter 'CA C3 ne 4D (CR)! 

This will yield the beginning and ending address of the program. (And 
in this case of the line itself.) List out the bytes by typing in the 
starting address, a veriod ('.'), and then the ending address. (HXemember 
that the low= ard higheorder bytes are reversed when looking at $CA,C5 and 
$4C ,4D.) On a 48K sytem this would yield: 


BFFB- 05 GA OO Gt 
CYPPG~ PD 


'5D* is the token for the 'REM® part of the line. What we need to do 
is to change this to 'QC' for 'CLR*®. There are two ways to do this. The 
first is to recognize that ‘BFKB’ is the address of the first byte shown 
on that line, namely the '95'. Counting over, we see that the '5D' is at 
hex address S$EFFE. Now, change the contents of this location by typing in 
'BFFF: @C (CR)*. 

If von are uneomfortable with the hex notation, there is a second way. 
Using the "ESCAPE* and 'D'key, move up until the cursor is on the same 
line as the 'BFFB'. (It should probably be on the first 'F' in 'BEFB") 

Now use the ‘ESCAPE’ and 'B' key to move to the left one space.. The cursor 
should now be on the 'B*. Now use the right-arrow key to copy over the 
addrss. When the cursor is over the hyphen ('=') enter a colon (':'). 

We have just simulated typing in 'BFFB: '. Now use the right-arrow key 
again to copy over everything on the line. Stop when you get to the ‘5D'. 
When the cursor is over the '5* in '5D* tyve in '6C' and oress 'KETURN®. 

Using either method we should now heve an ‘OC’ where the '5D' used 
to be. You may want to list it to check by typing 'BFFB.COGd (CR)'. 

Now 'Control=-C* to Basic and LIST. The program should now be: 


16 CLR 


Just what we wanted! HIMEM: and LOMsM: can also be entered in a 
similar fashion. The main restraint to replacing tokens is that whatever 
you tyve in for the temporary values must take up the same number of tokens 
as what you are going to replace it with. The new tokens must also still 
have the correct syntax, and since you are defeating having the computer 
check the syntax you must do this yourself. You must make sure that the 
new set of tokens taken as a whole for that line are consistent with what 


the Apple expects to find there. 
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For HIMEM: and LOMEM: '*PR#! may be used as your temporary statement. 
For instance, to end up with a line with "HIMEM: 8192' in it, first type 
'PR# 8192" in the appropriate spot. Then replace the '7E* token for PR# 
to a: *9* or "19! for *HIMEM:', 

After all this, where does LINE FIND fit in? In our examples, the 
line was easy to find because the programs were very short. However, for 
a long vrogram it would be very tedious to try to find a line in the middle. 

Solution? Just use the LINE FIND program, telling it what line # 
you're looxing for. It will find the line, give you the hex starting and 
ending addresses of that line, and leave you in Monitor to list out the 
bytes. Just type in the starting address, a period, and then the ending 
address. Now you can alter anything you wish. 


RECOVERING GARBAGED PROGRAMS 


Cecassionally during transfer of a program, or because of a faulty 
RAM chin, a program will drop a bit somewhere. If the alteration is in 

the middle of a line, where you had a 'PRINT® will suddenly become ‘HIMEM: ' 
or some similar item. You should now be alble to understand how a random 
error can produce a seemingly intelligent series of letters. What was 
changed was the single token for ‘PRINT’, it now being interpreted as 

"UIMEM' or whatever. This is usually easily fixed however by just retyping 
the line. 

The problem comes when the alteration occurs ina more crucial place. 
Namely, one of the first three or the last byte. If the first byte is 
changed, the program will LIST out o.k., but ‘hang’ on this line when you 
attempt a ‘FUN'. If either the second or third bytes are changed the 
line # of that line will be altered, vossibly disturbing the logic of execu- 
tion of the program, or defeating GOTO's referenced past that line. If the 
last byte is changed, the two lines on either side of the '@1' become merged, 
usually with the second line listing as gibberish, (‘the effect of having 
the syntax of tokens disturbed) In fact, the alteration of this one byte 
can make enough of a difference to have the entire program from that point 
on list as nonsense. 

LINZ FIND can be used on oecasion to recover damaged programs because 
you can look directly at the part of memory where the problem is. There is 
no standard method for repair, but in general follow this procedure: 

First determine which of the four tyves of vroblems above have occurred. 
If you have just a bad byte within the line retype it. If the line # has 
been changed, several things may happen. If the line # is lower than the 
other line #'s preceeding it, vou will not be able to delete it. If it 
equals a line # already therebefore it, attempting to delete it would only 
delete the other line. In general, the solution is to use the LINz# FIND 
program to fird the line just ahead of the damaged one. ‘hen go in and 
look at the next 3 bytes after the '@1' at end of the one you found. Bytes 
2 and 3 are the altered line # bytes. Chances are only one of these two 
has been altered. Restore these two to the low- and high-order bytes for 
the line # you want there and your problem should be solved. (Use ADDRESS/ 
HEX CONVERTER if you are unsure what the two bytes should be for the line #) 
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If the system thangs’ on a given line, use the LINz FIND program to 
find that line number. The ending address that it gives you will not be 
correct but the starting address will be. Then examine the part of memory 
after the starting address (for up to 255 bytes) to try to determine where 
that line actually ends. Things to look for are the '@i' at the end of the 
line (although this may occur as part of a constant or referenced line # 
as discussed earlier) or use the ADIRESS/HEX CONVERTHR to determine the 
lowe and high-order bytes for the number itself of the next line, and look 
for these. When you have determined where the line ends, you must then 
determine its length and put this value back into the first byte. You may 
find the built-in hex subtraction routine in Monitor helpful. Subtract the 
starting address (in hex) from the ending address to determine the length. 

If the problem is merged lines then the last bit of the line has been 
changed from '@1" to something else. Use the LINE FIND program to find 
where the line was supposed to end and put an '@1' there. This should do it. 

These techniaues should solve many of the problems encountered in 
damaged programs. It may seem a bit involved, but it is easier than retyping 
an entire vrogram - or not having one at all if it's one you bought!. It 
does take a little effort and careful thought, but can be very educational 
in the process. Good luck! 


Both LINE FIND-I and LINZ FIND-A/S are good for learning how lines in 
either language are tokenized. To experiment, type ina line, then run 
LINS FIND. After listing out the line in Monitor, use 'Control-C' to 
return to Basic and LIST the line to compare the two. Then make any changes 
you wish and execute the appropriate ‘CALL ...' to re-activate LINE FIND. 

You can do this over and over again to see just how each kind of line 
is formatted. 


HIMEM: 
(End of Line) 


_ (Underscore ) 
; (Stmt sep.) 


LOAD 

SAVE 

CON 

RUN 

RUN 

DEL 

» (for DEL) 
NEW 

CLR 

AUTO 

,» (for AUTO) 
MAN 

HIMEM: 
LOMEM: 


+ 


te SSPE NS Se Pg 
nw an rT ¥ 


qernenee ea" 
a 


THEN (line #) 
THEN (Stmnt) 
» (String) 
» (Variable) 
" (Beginning) 
'' (Ending) 
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Hex. Char. Dec. 
2B t 85 
<C t 86 
2D. 87 
2E PHEK 88 
2k RND 89 
3 SGN 9¢ 
31 ABS 91 
32°. PDL 92 
33 RNDX (7) 93 
34C~C«‘«‘C 94 
35.0 + 95 
36 «0 (Signs) 96 
37. -—s* NOT 97 
48... £ 98 
39° = 99 
34 Ci# 16¢ 
3B Ss LEN( 1¢4 
3C. 3 ASC 12 
3D = SCRN 143 
3E ; 104 
SF ¢ 105 
4G ¢$ (String) 146 
hie 107 
cr | 428 
ig ee 109 
pe 11¢ 
ee 111 
LG : 1i2 
147 P 4:13 
1 114 
49, £15 
A 116 
4B TEXT £17 
4c GR 118 
4D CALL 119 
ue DIM (String) 120 
uF DIM (Variable) i121 
52 TAB 122 
pes END 123 
52 INPUT (String) 124 
53. INPUT ($ or Var.125 
w/ wee ) 126 
54 INPUT (Var.) 127 
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Hexe 


Char @ 


LET 

GOTO 

IF 

PRINT (* *) 
PRINT (X,X$) 
PRINT (Null) 
POKE 


= (Stringz) 


NH NL 


LIST (From-to) 


9 

LIST (Entire prog.) 
POP 

NODSP (String) 
NODSP (Var.) 
NOTRACE — 

DSP (String) 
DS? (Var. ) 
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Dec. Hex. Char. Dec. Hex. Char. Dec. Hex. Char, (Printer-lwr.case) 
128 86 Spe.° {Ji AB + 214 Dé V 
129. 81: ac sig eee eee e25: 7 = 
13g 82 « 193°. AB SS 216- pe -x 
13: 83.CS Se eae 217 D9 XY 
132 6h 7S. BFF 218 DAZ 
133 85 «5 176 BO 219 DB f 
134 86 FC 177 Ba 228 De \ 
135 87. Ge i76 wm. 3 Sot Pp 3 
136... 68. #° 179° = BB 3 222. Te A 
137 189 Bh 4 223... 
138-84... a= it BS 224 EG Space * 
139. 48... = 182 3% 6 $25 Wt (a) 
{hg Be Ee oy ee  F 226 £2 # (b) 
141 8D MS 184 B58 8 ge7 Ee (c) 
142: . 8s 3 165 oO 9 228 #8: $ (d) 
{43 fe 186 BA: 229 £5 #4 (e) 
tus. Of pe 187 EBB : 230 26 & (f) 
145 OE = GS 168. fC < 251 ee (g) 
G2. Re 189 BD = 232° .8 ( (h) 
$F. 2 93. Se 199 EE > 233. EOC) (i) 
148 94 fc iol. we 2? 234 EA * Ci) 
149 «95 = 192 cd G& 235 EB + (i) 
150 96 = 195. tb AK 296° “EE oy (1) 
151 97 Ke {oh = @ 2B 237. ED. = (m) 
152. 3%. xt 195: > C€ Soe... Ee ss (n) 
155. 99 =x 196 ch oD 239 EF / (0) 
tsk: A: 7 197. ¢5  £ 240 FG G (p) 
155 9B se. or co 198 c6 F aut FL 1 (q) 
is6é oc. << 499 C7: GG 242 F2 2 (r) 
157. 9p. 3° 206 c8 4 243. «F333 (s) 
158 Oe Ao ani ocr 2u4 FL 4 (+) 
169 98 = age CAC 245: -F5. 5 (x) 
160 A@ Space 203°. -€B - & 246 FO 6 (v) 
14) Mt 20 EL a7. EF. 7 (w) 
162-12 * 265 cD ©sM 2u8 F8 8 (x) 
163 age # 206 Ce <N 249 FO 9 (y) 
164 ak 207: GF CO 250 FA: (z) 
165 a5 ot 208 DS P 251. FB; £ 
166 A6 & 209 Di Q 252 . PECeoZ / 
{491 go 216. f2 oR 253 FD = } 
168 as ( 214 PS 254 ed i 
169. - Ao.) 212 ft 255 FF ? 
178° Ae 213°-DS. 8 
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INTERNAL STRUCTURE OF APPLESOFT 


This section will deal with how Applesoft is formatted as opposed to 
INTSGER. It will be assumed that you have already read the material on 
INTEGER, or are fairly familiar with how INTHGER is set up. For a list 
of Applesoft Tokens, see the green reference manual, pgs. 138,139 and 
121. The ASCII values given on 138,139 are the same as the tokens used 
to encode these characters in memory. 

The first difference between the two languages is the location of 
the beginning and end of program pointers. In Applesoft, the beginning 
is held in $67 and $68 (dec. 193,194) and the end in SAF and $BQ (dec. 
175,176). Get Avovlesoft up and running, then tyne 'NEW'. Now type in 
the following program: "16 GOTO 20° 

'29 END' 


LIST to make sure you have done this correctly. Now type in 'CALL -151' 
to get into Monitor. Find the beginning and end of the program by typing 
'67 68 AF BO’ (carriage return will be assumed from now on unless other- 
wise noted). On a 48K system this will give: 


OG67— G1 (Note: If you have Applesoft in RAM the 
G068- 68 starting address will probably be $39¢1 
OGAF- 12 and end at $3912) 

O¢B¢- 68 

List out this range with 1801.812". This should give: 

68G1- 69 68 GA OO AB 32 30 (The last two bytes at $8t1 and 
$898- 06 OF 88 14 26 80 2B AG $812 may ve different...) 


G819- 20 OO GE 


The first two bytes of the line are an index to the address of the next 
line. In this case they point to $0899. The next two bytes contain the 
line # ("10"). AB" is the token for 'GOTO'. In Applesoft, constants 
and referenced line #'s are stored with one byte per digit. In our ex- 
ample, the number '20' is stored as '2','%*', The end of the line is 
indicated with a '@@'. The next line continues in a similar fashion. 

'OF G8" indicates that the next line would start at $80F. "14! and 
"39" are the low- and high-order bytes for the line number '26'. '89@! 
is the token for *END* and '@6 indicates the end of the line. In Apple- 
soft, the end of the line is always easy to spot because it is the only 
time '$' is used. Applesoft knows where the end of the program is, not 
by using the pointer at $AF,B@, but by finding '§¢ 60" when it looks for 
the index at the end of the program. (In this case at $80F and $816.) 

SAF and $B@ must point to an address no smaller than these two zeros, 
but it may point to any address after this. 

(Nete: you may find it helpful to use the ADDRESS /HEX CONVERTER to 
determine the hexadecimal values for the tokens on og. 121.) 


[3 
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The pointers at $A4F and $B% are used when LOADing and SAVEing a program, 
but not during a 'RUN'. In fact, this is very useful because you can store 
any kind of binery data you wish (machine language programs, screen images, 
etc.) within your vcrogram space by just pointing $AF and $B0 at a suitable 
location beyond the true end of the program and storing your binary data 
in the created space. You may SAVE and LCAD it just as you would any program 
and the binary data will be carried along right with it. 

Since Applesoft does not check syntax until it RUNs s program, inserting 
what you want in a program line is not a prbdlem, but recovering garbaged 
programs still is. In Applesoft, if the lst or 2nd byte is altered, strange 
things may happen. Lines may merge or repeat indefinitely or just dis- 
appear. Usually what harpens is that the listing becomes nonsense after 
a certain point. The next two determine the line number, and if these are 
changed it is similar to what can happen with INTEGER. If the last byte 
is changed, the program will LIST properly, but during a ‘RUN’ you will get 
a "SYNTAX ERRCR* on that line for no arparent reason, stopping execution. 

The procedure for fixing these problems is similar to that in INTEGER. 
If the first two bytes are suspected, find the last intelligent line # in 
the listing. Then go into Monitor and look for the '@@* at the end of the 
line. The index in the first two bytes of the line should point to the 
address right after the 'd@', 

If the line # is altered, use LINE FIND to locate it if you cannot 
change it directly. If thereare no lines before it with the same # you may 
search for it directly with the program. Otherwise, locate the line just 
before it, find the '@@* at the end of that, and then put the correct low- 
and high-order bytes for the line # you want there into the 3rd and 4th bytes 
of the altered line. If the last byte is bad, use LINE LINE FIND to get the 
ending address and put a '@' in the last byte of the line. 
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Dec. Hex. Char. Dece Hex. Char. Dec. Hexe Char. (Printer-lwr.case) 
g g¢ € 43°. 2B + 85 55:0 
4 40 Ae Ua OO 86 56 2V 
2 208 Be 45 2D - 87 57 WwW 
3 220 “6 26s 88 58k 
yo ee py Te ed ees | 69. 59... -E 
5. 5 48 3 @ Of 5A 
6 6 FF os pees ener 91 pi: ieee * 
(eee! Gr 50 32-2 G2. BERN 
8 8 H ee Mane 93 DDE a 
9 oe he 52 34 4 94 So SA 
12 A ge 53.95 5 95 bate 
14 RB Ke 54. 36 COG 96 66 Snace ‘ee. 
12 Ce 65377 OF 8 69 2 (a) 
13 Dp we 56. 38 8 08 62.0." (b) 
14 BN 57 39 G9 99 63. # (c) 
15 rF 6 58 3A: 196 64; (da) 
16 16 Ff 59 3B; $01 5-05 (e) 
‘8 42 61° 3D = 103.5. 675% (g) 
9 13-° S° 62 3h (Gb 68 (h) 
7A) ees | ee oe 63. 23F 9 1g5. 69) (i) 
Fo AG 64 4 @ 106° 6A (3) 
22 #16~=«O¥ 65. = Stok 197 6B + (k) 
23-17 we 66 42 B 148 66.4 (1) 
a -48.- xe 67 43° =«C 109... 6D. (m) 
$8 99 68 44 D HG OES. (n) 
26: 1A. Ze 69 45 & 111 ee A (o) 
27 1B BSCare 70 46 F 112 70 Q (p) 
28 ic ve 7 87 SG 3 7 (q) 
29. 1p. 3° 72. 46H 114 72.52 (r) 
90° 1B 4. 7 89. I ibs gene as (s) 
3 ae 7. Wh J 116 7 4 (t) 
32 28 Space 75 HEX 117 (eae. (u) 
93°21 et 76 WOE tee 76 6 (v) 
34 22 19 77 4D M 119 77 f (w) 
35° 5932 4 78 +%4YeE N 120 76° & (x) 
36 hg 79 4F 0 3 aa 6: (y) 
38° 26. & S20. 5h Q 123 9B ({) 
a9. 39,. 9 aly Aad 124 Fe oS Cc) 
id 28 a5 53S 125 7D = (7) 
by 39°.) 84 Sk 426. Te oy 
42 2A * 127 7 ? 
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Char, Dec. Hex. Char. 
END 171 AB GOTO 
FOR 172 aC RUN 
NEXT 173 AD IF 
DATA 174 AE RESTORE 
INFUT 175 AF & 
DEL 176 BS GOSUB 
DIM 177 Bi RETURN 
READ 178 B2 REM 
GR 179 #33 STOP 
TEXT. 186 BY ON 
PR# 181 BS WAIT 
IN# 182 B6 LOAD 
CALL 183 B7 SAVE 
PLOT 184 388 DEF 
HLIN 185 B9 POKE 
VLIN 186 BA PRINT 
HGR2 187 BB CONT 
HGR 188 BC LIST 
HCOLOR= 189 BD CLEAR 
HPLOT 199 BE GET 
DRAW 191 BF NEW 
XDRAW 192 cH TAB( 
ETAB 193 ci TO 
HOME i194 c2 FN 
ROT= 195 ¢3 SPC( 
SCALE= 196 ch ‘THEN 
SHLOAD i97  €5. at 
TRACE 198 C6 NOP 
NOTRACE 199 C7? STEP 
NORMAL 290 c8 + 
INVERSE 291 C9 - 
FLASH 262 CA §# 
COLR= 263 cB / 
POP 204 CO OA 
VIAB 205 CD AND 
HIMEM: 206 CE 
LOMEM: 207 CF >» 
ON ERR 298 Dp = 
RESUME 229 Di < 
RECALL 219 D2 SGN 
STORE 211 D3 INT 
SPEED= 212 De ABS 
LET 213 DS USR 
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